• feat: simplify #1589
• feat: refactor + improve stability #1585
• feat: improve tests, fix cache and fix package #1566
• feat: Break up god class #1565
• feat: Extract helpers #1564
• feat(code): port posthog detection logic to new pkg #1562 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

i'm not allowed to review this cuz github still considers me the author lol

but i see there are a lot of changes, just checking this could still be used in the vscode extension to replace the existing tree sitter service?

also looping in @fercgomes , any concerns w/ updating vscode ext to grab the pkg from here?

also looping in @fercgomes , any concerns w/ updating vscode ext to grab the pkg from here?

Just so I understand the context: is this the actual logic from the extension, or is it a parallel implementation with the same goals?

@fercgomes the goal is for posthog code to have the same sort of event/flag/etc detection that the vscode extension has. we want to use it in a few places -- injecting into agent context, showing in diff reviews, etc

this base PR is, i think, a pretty direct copy of the logic from the extension (though it is 100% vibe-ported)

@k11kirky has made some changes upstack but i think it's still the same logic, peter can you confirm?

@fercgomes the goal is for posthog code to have the same sort of event/flag/etc detection that the vscode extension has. we want to use it in a few places -- injecting into agent context, showing in diff reviews, etc

I love that the core logic is being reused, but in that case, doesn't it make more sense to have it in a separate repository? Maybe there are other teams who might benefit from this sort of source code detection, so it may be better to develop it in a more decoupled way.

@fercgomes i'm fine with a separate repo, but don't have a strong opinion - as long as we publish it as a package that's easy for other teams to consume then i'm cool 😄

Yes, this is a direct port of the detection logic from the VS Code extension — same tree-sitter approach, same patterns. The plan is to keep it as a published package (@posthog/enricher) that both this app and the VS Code extension can consume.

Re: separate repo — happy to move it out if that's the preference. For now it lives here since we're iterating on it alongside the desktop app, but once it stabilizes it could easily be its own repo. @adboio @fercgomes lmk if you'd prefer to move it sooner.